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FOREWORD 


The Software Engineering Laboratory (SEL) is an organization 
sponsored by the National Aeronautics and Space Administra- 
tion/Goddard Space Flight Center (NASA/GSFC) and created for 
the purpose of investigating the effectiveness of software 
engineering technologies when applied to the development of 
applications software. The SEL was created in 1977 and has 
three primary organizational members: 

NASA/GSFC, Systems Development Branch 

The University of Maryland, Computer Sciences Department 
Computer Sciences Corporation, Systems Development 
Operation 

The goals of the SEL are (1) to understand the software 
development process in the GSFC environment; (2) to measure 
the effect of various methodologies, tools, and models on 
this process; and (3) to identify and then to apply success- 
ful development practices. The activities, findings, and 
recommendations of the SEL are recorded in the Software 
Engineering Laboratory Series, a continuing series of re- 
ports that includes this document. 

The authors of this document are 

Kelvin L. Quimby (Computer Sciences Corporation) 

Linda Esker (Computer Sciences Corporation) 

Single copies of this document can be obtained by writing to 

Systems Development Branch 
Code 552 

Goddard Space Flight Center 
Greenbelt , Maryland 20771 
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PRECEDING PAGE BLANK NOT FILMED 


The software engineering issues related to the use of the 
Ada programming language during the design phase of an Ada 
project are analyzed. Discussion shows how an evolving 
understanding of these issues is reflected in the design 
processes of three ^generations* 1 of Ada projects. 
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EXECUTIVE SUMMARY 


During the past 4 years, the National Aeronautics and Space 
Administration/Goddard Space Flight Center (NAS^/GSFC) with 
support from Computer Sciences Corporation (CSC) has been 
using the Ada programming language in five different proj- 
ects. The first two of these projects, the Flight Dynamics 
Analysis System (FDAS) and the Gamma Ray Observatory (GRO) 
Dynamics Simulator in Ada (GRODY) , were research-oriented 
projects. The three Ada projects that followed are produc- 
tion satellite simulation systems for use in support of ac- 
tual missions. The Geostationary Operational Environmental 
Satellite-I (GOES-I) will be supported by the GOES-I Dynamics 
Simulator (GOADA) and the GOES-I Telemetry Simulator 
(GOESIM) . The Upper Atmosphere Research Satellite (UARS) _ 
will be supported by the UARS Telemetry Simulator (IJARSTELS) . 

This report analyzes the software engineering issues related 
to the use of the Ada programming language during the design 
phase of an Ada project and discusses how an evolving under- 
standing of these issues is reflected in the design proc- 
esses of three "generations" of Ada projects: FDAS and 

GRODY, GOADA and GOESIM, and UARSTELS . The following points 
summarize this analysis: 

• The GRODY project introduced object-oriented design 
and the entity-diagram notation, both of which have been 
adopted by all of the other Ada projects. However, GRODY 
was inadvertently designed in a way that required expending 
considerable effort in restructuring very large software 
modules into smaller ones so that they could be reused in 
subsequent Ada projects. The mathematical algorithms from 
GRODY continue to be widely used on all subsequent simulator 
projects . 
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• The FDAS project initiated the extensive use of 
small, separately compiled software components as a mechanism 
to modularize loosely coupled design elements and the use of 
type packages and subsystems as design entities. 

• The GOADA project formalized and expanded the use 
of subsystems as a design entity, examined the best features 
of the GRODY and FDAS entity diagrams, and incorporated 
these into an improved form of design notation; it was the 
first project to develop a compiled design. 

• The UARSTELS project, which greatly increased the 
use of Ada generic packages, was the first project to empha- 
size during design the development of software components 
that could be reused on subsequent projects without changes. 

4 The incremental design approach used on the produc- 
tion Ada projects meshes well with the existing preliminary 
design review (PDR) /critical design review (CDR) approach 
that has been utilized on traditional FORTRAN systems. The 
modifications made to this approach that are Ada-specific 
include the use of the entity diagram notation for both the 
preliminary design report (for PDR) and the detailed design 
document (for CDR). In addition, for the PDR most of the 
Ada package specifications to be used in the system are com- 
piled, and for the CDR the matching Ada package implementa- 
tions with program design language (PDL) are developed and 
compiled to the point that the code associated with the de- 
sign can be linked into an executable image. 

• Additional thought needs to be given to how to more 
effectively exploit features of Ada to maximize the amount of 
reusability of Ada software design components from one simu- 
lation project to another. Consideration should be given as 
to how to develop these design entities so that they are 
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reusable on larger systems, such as Attitude Ground Support 
Systems (AGSSs), and even on very large-scale systems, in- 
cluding the Space Station project. 
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SECTION 1 - INTRODUCTION AND BACKGROUND 


1.1 INTRODUCTION 

This report is the first of a series of four reports de- 
scribing the growth of Ada technology at Goddard Space Flight 
Center (GSFC) and Computer Sciences Corporation (CSC) . This 
technology continues to evolve through an accumulating ex- 
perience base gained from the development efforts associated 
with several past and current Ada projects at GSFC/CSC. 

This first report is primarily concerned with the evolving 
understanding of software engineering issues related to the 
use of Ada during the design phase of a project. Additional 
reports are scheduled to follow, one covering the evolution 
of Ada technology in implementation and one covering test- 
ing. A final summary report on Ada project characteristics 
will conclude the series. 

The first section of the report (Section 1) provides back- 
ground information, including a brief description of each of 
the Ada projects studied. Section 2 discusses the software 
engineering issues related to designing a system in Ada and 
how a growing understanding of these issues has been incor- 
porated in the design documentation generated for each new 
project. Section 3 presents the general project character- 
istics of each of the Ada simulator systems, including Ada 
experience and training of project personnel, Ada software 
metrics, and effort and productivity measures. Section 4 
summarizes the lessons learned in the design phases of all 
of the Ada projects and presents a number of recommendations 
to designing future systems in Ada. 

1.2 BACKGROUND 

Since 1960, GSFC has relied heavily on FORTRAN in developing 
software systems for mission analysis, satellite simulations, 
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and Attitude Ground Support Systems (AGSSs) . In 1985, GSFC 
and CSC began using the Ada programming language on two 
different types of projects. The first project to use Ada 
was an in-house, research-oriented project called the Flight 
Dynamics Analysis System (FDAS) . The FDAS project developed 
a software reconfiguration tool for use by National 
Aeronautics and Space Administration (NASA) analysts to ex- 
periment with different algorithms for solving spacecraft 
orbit and attitude analytical problems. Shortly after the 
decision was made to use Ada as the implementation language 
for FDAS, a second Ada project, called the Gamma Ray Obser- 
vatory (GRO) Dynamics Simulator in Ada (GRODY) , was started. 
This experimental Ada development project for use as part of 
the ground support system for the GRO satellite was the 
first attempt at using .Ada for the type of mathematically 
oriented system typically developed in this environment. A 
corresponding version of this simulator, the GRO Simulation 
Systems (GROSS), was developed in FORTRAN. The two simula- 
tor projects, GRODY and GROSS, were developed in two differ- 
ent languages to gain some understanding of the impact Ada 
is likely to have on the development of software in the 
flight dynamics area (Brophy et al., 1987; Godfrey and 
Brophy, 1987, 1989; Seigle and Shi, 1988). 

Both FDAS and GRODY can be characterized as research and de- 
velopment efforts because they were nonoperational projects 
for which a considerable amount of experimentation and/or 
prototyping was utilized in their development. Since both 
of these projects were first-time Ada projects for this 
environment, they are considered here as "first generation" 
Ada technology. 

With the development experience gained from these first-time 
Ada projects, the decision was made to use Ada as the imple- 
mentation language on two production satellite simulation 
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projects to be used in support of Geostationary Operational 
Environmental Satellite-I (GOES-I) . The first of these two 
projects is the GOES-I Attitude Dynamics Simulator (GOADA), 
which began on May 30, 1987, and completed detailed design 
on March 19, 1988. The second project is the GOES-I Telem- 
etry Simulator (GOESIM) , which began on September 5, 1987, 
and completed detailed design on April 30, 1988. Unlike 
GRODY, these projects are required to adhere very closely to 
project schedules. They can be viewed as "second generation". 
Ada projects because they have drawn heavily on the lessons 
learned from both FDAS and GRODY in their design. 

The most recent Ada project is also a production system to 
be used in support of the Upper Atmosphere Research Satel- 
lite (UARS) The UARS Telemetry Simulator (UARSTELS) proj- 
ect began on February 13, 1988, and detailed design was 
completed on September 10, 1988. Because this project has 
emphasized improving the designs of GOADA and GOESIM, it can 
be viewed as a "third generation" Ada project. 

Of the four satellite simulation projects, two are dynamics 
simulators, and two are telemetry simulators. For the pur- 
poses of comparison, the objective information presented in 
Section 3 of this document will be drawn from these four 
projects. For the analysis of this objective data, it is 
necessary to first discuss how an understanding of the tech- 
nical issues associated with designing software systems in 
Ada has evolved over the history of all five Ada projects. 
This type of subjective analysis is based on discussions and 
interviews with developers from the five projects, from ques- 
tionnaires filled out by these developers, and from published 
literature on both Ada and software engineering practices, 
in general. 
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SECTION 2 - ADA DESIGN METHODOLOGY 


2.1 OBJECT-ORIENTED DESIGN AND ENTITY DIAGRAMS 

The GRODY team intensely investigated various design method- 
ologies that could be used in developing a medium-sized Ada 
software system, and eventually adopted a modified version 
of object-oriented design (Agresti et al., 1986; Godfrey and 
Brophy, 1987; Seidewitz and Stark, 1986). This decision con- 
tinues to exert a strong and growing influence over subse- 
quent Ada projects and, as such, represents one of the more 
important contributions GRODY has made to the evolution of 
Ada technology at GSFC/CSC. 

Closely related to the design methodology is the issue of the 
representation of the design on paper. The previous design 
study has noted that documenting an Ada design, in particular 
when object-oriented design techniques are used, requires 
different design products than typically used for FORTRAN 
systems (Godfrey and Brophy, 1987). The object or entity 
diagram notation introduced by GRODY for graphically repre- 
senting Ada designs has been adopted by the subsequent Ada 
projects, each of which has introduced further refinements 
and enhancements to the graphic notation. These design dia- 
grams will be used throughout this section to illustrate the 
various points being made. 

The GRODY team developed a notation for representing basic 
Ada components based on ideas from George Cherry's process 
abstraction methodology (PAMELA) (Cherry, 1985) and Grady 
Booch’s object-oriented design (Booch, 1983). Bubble/ 
rectangles (bub-tangles) are used to represent packages; 
rectangles are used to represent subprograms; and parallel 
lines are used to represent state data (Figure 2-1) . These 
symbols continue to be used on the current projects. 
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The major advantage of the graphic representation introduced 
by GRODY is the ease of representing the design of an entire, 
medium-sized project within a three-ring notebook, with a 
simple notation that is easy to understand and draw by hand. 
The hierarchical structure of a system is indicated by the 
use of leveled diagrams, with off-page connectors illustrat- 
ing the top-down relationships among components that span 
page boundaries. 

The FDAS team felt that additional information was needed on 
these diagrams to specify the bottom-up relationships among 
components that spanned page boundaries. For example. Fig- 
ure 2-1 from the GRODY system description document illus- 
trates that it cannot be determined from looking at the 
design diagram what particular entities reference the opera- 
tions Initialize_Error_Log, Terminate_Error_Log, and Update 
Error_Log. This type of information is important because 
the design notebook is, in reality, a medium for communica- 
tion between developers. Thus, when the individual in 
charge of developing Error_Logger adds, deletes, or modifies 
any of the formal parameters associated with the three visi- 
ble operations mentioned above, that individual knows what 
components outside of his or her domain are affected and can 
notify the individual (s) responsible for developing those 
components. FDAS added this type of information to their 
design notation by providing the page connector symbol and a 
number that indicated the location of the component (s) that 
reference the entity on the diagram (Figure 2-2) . 

The entity diagram notation introduced by GRODY has provided 
a firm foundation for refinements and enhancements that have 
been incrementally introduced by subsequent Ada projects and 
can be expected to further evolve as more advanced features 
of Ada are adopted on subsequent projects. 
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2.2 


The idea of Ada subsystems, a very important design concept, 
was introduced after GRODY. A subsystem in Ada is an ab- 
stract entity that is composed of a number of Ada packages, 
subprogram compilation units, and possibly other lower-level 
subsystems (Booch, 1987). It is an abstract entity because 
no specific Ada component is used to represent a subsystem. 

A subsystem is analogous to a package because generally some 
of the constituent components that make up the subsystem pro- 
vide visible operations to users of the subsystem, whereas 
other constituent components are hidden (Figure 2-3). 

Subsystems were first used as a design entity in the FDAS 
research project, and the concept was formalized and expanded 
by the GOADA project. Subsystems were not used in GRODY be- 
cause of the team's interpretation of what an object is in 
object-oriented design. To GRODY, the Ada package was the 
de-facto implementation vehicle for objects. Thus, all ob- 
jects were represented as a single package. If the object 
were too large to be implemented in its entirety by a single 
package, it could be decomposed into lower-level packages, 
but the operations on the object were constrained to be 
implemented within a single, top-level package. Thus, in 
GRODY, an object always had a single package as its root. 

Using this approach, the decomposition of an object into 
lower-level packages required that the specifications of 
these packages had to be tied to the root package through 
one of the following: 

1. Physically nested within the root package specifi- 
cation 
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2. Implemented as library units or physically nested 
within the root package specification or body but 
accessed by components outside of the root package 
via call-throughs 

3. Implemented as package specifications that contain 
Ada renames statements for indicating visible opera- 
tions 

Utilities, the entity in GRODY that illustrates approach (1), 
is a package instantiation of Generic_Utilities composed of 
a number of lower-level packages, including Math_Functions , 
Linear, and Attitude_Math. These three math packages were 
physically nested within the specification of Generic_ 
Utilities, and their operations could only be accessed 
through the instance name Utilities, such as Utilities .Math_ 
Functions .Sin, Utilities .Linear .Unit_Vector , etc. With this 
approach, all operations or services provided by the sum of 
the constituent packages of the object have to be provided 
within the single root package specification of the object, 
even if those operations or services are organized into 
lower-level packages. Thus, for Generic_Utilities , the 
specifications for a total of 49 procedures and functions 
were provided within the single package specification 
Generic_Utilities . 

A number of problems exist with this approach that were not 
apparent to the GRODY team at the time the system was de- 
signed (Clarke et al., 1980). The major problem addressed 
in this section is that this approach does not scale-up well 
from small programs (Booch, 1987). A utilities object de- 
signed this way in a large-scale Ada system, such as the 
Space Station, might contain several dozen math and other 
utility-package specifications nested within the specifica- 
tion for the object Utilities and, therefore, hundreds of 
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subprograms specified physically within this one large pack- 
age. Since almost every component in such a system would 
have to access one or more packages within Utilities, hun- 
dreds of thousands of lines of Ada code would have to be 
recompiled every time the slightest modification were made 
to the specification of Utilities, even though that modifi- 
cation may have been made for the benefit of only a few 
packages within the entire system (such as changing the mode 
of a single parameter within a single routine within one of 
the nested package specifications). In structured design 
terminology, such a system contains modules that are tightly 
coupled (Myers, 1978). 

In Build 1 of FDAS, the package Utility was designed just as 
on GRODY in that its constituent packages were physically 
nested within the package specification of Utility. How- 
ever, by Build 2 of FDAS, Utility had evolved into the kind 
of abstract entity described above (Figure 2-4). The four 
packages nested within the package Utility were extracted, 
renamed, and compiled as library units (Figure 2-5) . The 
package Utility itself was discarded, but the entity was 
retained as a design concept. In other words, Utility be- 
came a subsystem as defined by Booch (1987). 

The problem with the design diagram from FDAS is that it is 
not readily apparent from the diagram which entities are 
packages and which are subsystems. The trailing underscore 
in the name Utility_ was meant to indicate that it repre- 
sented a collection of packages, with the convention that 
each package in this collection would begin with this name 
(i.e., Utility_Host_Command_Handler , Utility_Log_File_ 
Handler, etc.). However, this was found to be unnecessarily 
restrictive because this forces verbose package names. (The 
package Conf iguration_Management in the subsystem Flight 
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Computer Operating System described by Booch (1987) would 
become Flight_Computer_Operating_System_Conf iguration_ 
Management.) What was needed was a different symbol to 
easily distinguish packages from subsystems. Such a symbol 
(an elipse) was introduced by the GOADA team (Figure 2-6) . 

The use of subsystems as a design entity has eliminated the 
rationale for nesting Ada packages inside other Ada packages 
and, as such, has eliminated the need for the use of subpro- 
gram call-throughs . This, in turn, allows the design of 
loosely-coupled, modular systems, enhances localization, 
permits the development of verbatim reusable components, and 
minimizes recompilation overhead associated with the inevi- 
table changes that occur during development. 

2 . 3 TYPE PACKAGES 

Ada package specifications have proven to be useful mech- 
anisms for modularizing the declaration of types and con- 
stants that are used by various library units. Although 
Types packages were used somewhat in GRODY, they were not 
specified in the design documentation. This information was 
deemed necessary by FDAS; therefore. Build 2 Types packages 
were placed on those particular pages of the design notebook 
where all or almost all of the entities on the page refer- 
enced these packages (Figure 2-7). As a result, it was easy 
to determine which design components might be affected by. a 
change in a particular Types package. On GOADA, a specific 
symbol was introduced for the Types package, borrowed from 
the symbol Booch (1983) uses to indicate the types exported 
by a package. This technique has been adopted by GOESIM and 
UARSTELS (Figure 2-8). 

2.4 REUSABLE SOFTWARE COMPONENTS IN DESIGN 

The GOADA project introduced the use of two vertical parallel 
lines near the sides of a package or subprogram symbol to 
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Figure 


STRUCTURE DIAGRAM NOTATION 

Subprogram - a procedure or function 

Reusable Subprogram (<25% change) 

External Subprogram - subprogram passed into a 
generic instantiation 

Package - collection of logically related subprograms 
Reusable Package (< 25% change) 

Verbatim Reusable Package 




( -types) 


Subsystem - collection of logically related packages 
Type Package - a package containing type definitions only 


ZZ7 


Task - concurrent or parallel process 


Package Stale Memory - local variables in a package 



— label ► 


V 


External Call - call to or from a routine not in the package 
Control Flow - a call (also dependence) ® 

S' 

Data Flow - direction and description of data g 

Generic Instantiation - creates a copy of the code 


2-8. Structure Diagram Notation Used on Most 
Recent Ada Project (UARSTELS) 
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indicate that the component is being reused. The UARSTELS 
project expanded on this idea by providing additional infor- 
mation to indicate if a component is being reused with some 
modifications (less than 25 percent change), or if it is 
being reused verbatim, i.e., reused with no modification to 
the source code of the component (Figure 2-8). 

An increasing emphasis on the verbatim reuse of Ada compo- 
nents in design has resulted in additional symbols associated 
with generic packages. The GRODY project introduced the use 
of a dotted arrow to point from the instantiation of a gen- 
eric package to the actual generic package that was used in 
the instantiation. (An example of this from GOADA is shown 
in Figure 2-9.) This is consistent with the idea that the 
generic instantiation is dependent on the generic itself. 

The GOADA project introduced the use of a dotted box to in- 
dicate a subprogram that is passed as a parameter into a 
generic instantiation. (Figure 2-10 shows example from 
UARSTELS . ) 

The additional symbols for type packages, reused components, 
generic packages, and generic instantiations continue the 
evolutionary process of directly mapping an Ada design 
entity into a specific type of Ada software component. This 
evolution should simplify the developers' task of using the 
design document to implement the design of the system. 

2.5 COMPILED DESIGN 

The GRODY project investigated the concept of developing 
compilable design elements during the design phase of the 
software development life cycle. However, only a small 
portion of the system was actually compiled by the time of 
the CDR . The majority of the package specifications were 
compiled early in the implementation phase, including some 
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Spacecraft Hardware Subsystem Structure 


2. 1 .4 Simulation Scheduler.Dispatch Jivent 
2.2. 1 AOCS .Sensor Processors 

6.5 Database Manager. Route Update Request 

6.6 Database Manager .Route Retrieve Request 



1.1 User Interface Manager 

2.3.2 Attitude Dynamics 

2.3.3 Spacecraft Environment 


Etc. 


Etc. 


I 

C\J 


Figure 2-9. Example of Generic Package and Instantiation 
From GOADA Project 
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ORIGINAL PAGE IS 
OF POOR QUALITY 



End Generic Coarse Sun Sensor 


Figure 2-10. Design Diagram From UARSTELS Showing 
Subprograms as Parameters for Generic 
Instantiation 
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Ada PDL . Most of the GRODY team members felt that this com- 
pilation of software components and PDL should be considered 
as a design activity, with the compiler being used essen- 
tially as an interface and type-checking tool to verify con- 
sistency across the project (Godfrey and Brophy, 1987) . 

This idea from GRODY of developing compiled design elements 
during the design phase was adopted by all subsequent Ada 
projects, and the concept has been expanded to include de- 
velopment of a compiled design. This is a more rigorous 
concept because the term here has been defined to mean that 
all of the compiled design elements that make up the system 
must be sufficiently complete such that the entire system 
can be successfully linked into an executable image. 

A design in Ada can be compiled to different levels of de- 
tail: 

1. Compilation of the specifications and implementa- 
tions (bodies) of the packages within the system plus com- 
pilation of the program driver. At a minimum, this requires 
that the subprogram bodies implemented within the package 
bodies contain a null; statement: 

package body Generic_Thruster is 


procedure Model ( 

Thruster_ID: in THRUSTER_ID_TYPE ) is 

begin 
null; 

end Model; 


end Generic_Thruster ; 
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2. Same as (1) above, except each subprogram in each 
package body is separated into individual files and compiled, 
leaving behind in the package bodies only the stubs of these 
subprograms: 

package body Generic_Thruster is 


procedure Model ( 

Thruster_ID: in THRUSTER_ID_TYPE) 

is separate; 


end Generic_Thruster ; 
separate (Generic_Thruster) 

procedure Model (Thruster_ID: in THRUSTER_ID_TYPE) 

is 

begin 

null; 

end Model; 

3. Same as (2) above, except commented out PDL state- 
ments are included in the body of the subunits 

4. Same as (3) above, except control statements are 
compiled (loop ... end loop;, if ... then ... end if;, case 
. . . end case; ) 

5. Same as (4) above, except commented out calls to 
lower-level subroutines are included 

6. Same as (5) above, except calls to lower-level sub- 
routines are compiled 

In practice, most of the newly designed software components 
for GOADA, GOESIM, and UARSTELS have been compiled to the 
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level indicated in (4) or (5) above. This provides inter- 
face checking among all of the compilation units that com- 
prise individual packages and syntax checking of the control 
statements within subunits. However, utilizing the compiler 
to check interfaces across package boundaries requires com- 
piling to the level indicated in (6) above. In this case, 
all calls made to subprograms within lower-level packages 
referenced by a particular unit are coded and compiled. 

This requires that all variables used as actual parameters 
(arguments) in subprogram calls must be declared, and the 
types of these variables must be identical to the types of 
the formal parameters associated with the called subpro- 
grams. Since most of the executable code in non-terminal 
subprograms often consists of control structures wrapped 
around subprogram calls, many developers felt that units 
compiled to this level would be (for the most part) imple- 
mented before the implementation phase of the project had 
actually started. As a result, most developers indicated 
that a design should be compiled to the level that included 
compiled control statements within the PDL. The average 
level to which a design should be compiled, by project is 

GRODY GO ADA GOESIM UARSTELS 

3 4.4 5.2 4 

The introduction by the GRODY project of the concept of de- 
veloping compilable design elements during design has been 
expanded by the production simulator projects to include the 
development of a compiled design. 

2.6 PROJECT REVIEWS 

All four of the simulator projects have followed the tradi- 
tional approach utilized on FORTRAN systems of having two 
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formal design reviews, a PDR, and a CDR. Presently no reason 
appears to suggest that a different approach is required in 
this environment for an Ada project although consideration 
should be given to making some modification to the time these 
reviews are held during the project life cycle, as discussed 
below. 

2.6.1 PRELIMINARY DESIGN REVIEW 

Except for the specific references to structured design and 
FORTRAN language constructs, all four of the simulator proj- 
ects followed the steps outlined in the Recommended Approach 
To Software Development (McGarry et al., 1983) during pre- 
liminary design. Thus, for each project the high-level 
architecture of the system was defined, and each top-level 
subsystem was refined to two additional levels of abstrac- 
tion. The entity diagram notation was used to represent 
this design within the preliminary design report, which is 
the primary product of preliminary design. For the three 
production simulator projects, the Ada package specifications 
defined for the entity diagrams were designed, coded, and 
compiled, a process that is specific to using Ada. Finally, 
the design was subjected to formal management and technical 
review through the PDR. All four task leaders of the simula- 
tor projects indicated that the PDR was helpful as a part of 
the design phase of the software development life cycle. 

2.6.2 CRITICAL DESIGN REVIEW 

The development of a detailed design for each of the produc- 
tion Ada simulators also followed the traditional approach 
used on the FORTRAN systems, with the major exception that 
the design was compiled by the time of the CDR. The primary 
product developed during this phase was the detailed design 
document, which was produced by continually refining into 
greater detail the entity diagrams generated for the 
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preliminary design document. The other major product of de- 
tailed design was the code and PDL produced during develop- 
ment of the compiled design. For this part of the design 
phase, the package specifications compiled before the PDR 
were used as input to an in-house utility called Package_ 
Helper, which automatically generated compilable package 
bodies and compilable subprogram subunits as described above. 
The bulk of the remaining design work then involved develop- 
ing PDL within each of the subunits, and then compiling these 
units into the appropriate Ada library. Once these compo- 
nents were compiled, the entire system was linked into an 
executable image. 

The CDR appears to be a suitable, sufficient approach to 
formal review of the products of the detailed design effort 
by management and technical personnel. However, a number of 
developers expressed the opinion that the CDR on their proj- 
ect was held too soon after the PDR. These developers sug- 
gested that the schedule pressure to produce large amounts 
of compilable code and PDL by the time of the CDR did not 
allow a sufficient amount of time to think through the de- 
tails of the design. 
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SECTION 3 - PROJECT CHARACTERISTICS 


3.1 PLANS AND ESTIMATES 

As a part of the planning process, task personnel for each 
of the three production simulators estimated the total staff 
effort hours that would be required for the duration of the 
project based on prior experience with FORTRAN projects and 
the manager's guidelines for the Flight Dynamics area. 

During the requirements analysis and design phases of the 
project, GOADA required 8,144 hours, or 35.4 percent of the 
total hours estimated; GOESIM required 4,218 hours, or 
32.6 percent of the total hours estimated; and UARSTELS re- 
quired 3,008 hours, or 29.5 percent of the total hours 
estimated for the project. In comparison, the manager's 
guidelines, developed- in the Flight Dynamics area for plan- 
ning FORTRAN projects, suggest that the staff hours needed 
for requirements analysis and design should be 30 percent of 
the total effort for a project. The 30 to 35 percent esti- 
mated figure for the three Ada projects is similar to the 
30 percent figure used for the FORTRAN projects, but this 
may be because these Ada projects were planned using the 
same estimation techniques applied to FORTRAN projects and 
required to adhere to these planned schedules. For the GOADA 
project, most developers felt that insufficient effort was 
allowed for the detailed design, and those portions of the 
system that had not been fully designed by the time of the 
CDR were completed early in the implementation phase. There- 
fore, the 35 percent estimated effort for design for GOADA 
is likely to be understated. 

The Flight Dynamics area also traditionally estimaces an- 
ticipated life cycle phase start and end dates as a part of 
project planning. Task personnel on the three production 
simulator projects each took a different approach in 
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estimating what amount of calendar time the design phase 
would require as a percentage of the project life-cycle. On 
the GOADA project, 36.5 percent of the elapsed time of the 
project was planned for requirements analysis and design. 

On GOESIM and UARSTELS, this percentage was 46 percent and 
44 percent, respectively. By CDR, the planned dates had 
changed somewhat. GOADA had replanned, slipping the end date 
of system test by 1 month. GOESIM went to CDR 2 weeks late 
but adhered to the remainder of the schedule. UARSTELS went 
to CDR as originally planned. As it turned out, all three 
projects eventually allocated similar percentages of elapsed 
time to the requirements analysis and design phases: GOADA, 

43 percent; GOESIM, 49 percent; and UARSTELS, 44 percent. 

In comparison, the guidelines developed for FORTRAN allocates 
35 percent of the time scheduled for requirements analysis 
and design. This is 10 to 15 percent lower than what was 
experienced on the three Ada projects as of CDR. It will be 
interesting to see how or if the schedule changes after the 
implementation phases are completed on each of the three 
projects . 

3.2 DEVELOPMENT ACTIVITIES THROUGH DESIGN 

The profiles of these projects differ in terms of the dis- 
tribution of effort among the following categories of devel- 
opment activities up to the time of the CDR: 

• Predesign (PREDES) 

• Create design (CREDES) 

• Read and review design (RDREVDES) 

• Coding (CODE) 

• Other activities (training, meetings, technical 

management (OTHER) 
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Support (Program management, technical publications, 
librarian, secretarial) (SUPPORT) 




The research and development orientation of GRODY is apparent 
from this project’s activity profile (Figure 3-1). Nearly 
half (48.3 percent) of the effort was charged to the OTHER 
category, much of which included Ada training and work on 
developing a design methodology suitable for a system of 
this size. 

The next three projects that followed in time were the GOADA, 
GOESIM, and UARSTELS production projects. Since most of the 
technical groundwork on design issues related to Ada had 
been worked out by GRODY, these projects were able to devote 
the largest percentage of their activity to actually creating 
the design, and this percentage was very similar across all 
three projects — 41.1 percent for GOADA, 42.9 percent for 
GOESIM, and 38.3 percent for UARSTELS (Figure 3-1). 

3.3 REUSE 

The GRODY project had no flight dynamics software written in 
Ada to draw from and, as such, were not able to reuse any Ada 
code; the 3.7 percent reuse reported by GRODY was limited to 
imported FORTRAN procedures obtained from a previous dynamics 
simulator (Figure 3-2) . For the production Ada simulator 
projects that followed, a concerted effort was made to reuse 
this Ada software from GRODY. The component reuse percent- 
ages for the later projects were 42 percent for GOADA, 

30 percent for GOESIM, and 50 percent for UARSTELS (Fig- 
ure 3-2) . 

Unfortunately, the GRODY team did not well understand design 
considerations necessary for the implementation of Ada soft- 
ware components that could be readily reused on future Ada 
projects. This problem can be viewed in part as a result of 
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the team's lack of the use of subsystems as a design entity 
and an inappropriate use of nesting to enforce component 
visibility (Clarke et al., 1980). As a result, during the 
development of GOADA's compiled design, a considerable 
amount of effort was needed to extract software components 
from the heavily nested components of GRODY and then to re- 
construct these components into smaller, individual library 
units. This extra effort can be seen in Table 3-1, which 
shows the percentage of the total effort during the design 
phase spent on four special activities: documentation, 

enhancement and optimization, reuse of software, and rework 
needed as the project progressed through design. During the 
design phase, 8.1 percent of the total effort during the 
design phase was spent on reuse of software for the GOADA 
project as compared to 4 percent for the GOESIM project. 

The effort expended on reuse increased somewhat on UARSTELS 
(5.7 percent), primarily because many of the packages avail- 
able from GOADA were modified into generic packages. 

Table 3-1. Percentage of Total Effort Spent on Special 
Activities During Design 



GRODY 

GOADA 

GOESIM 

UARSTELS 

Documentation 

ND* 

19.7 

11.8 

13.3 

Enhancement and 
Optimization 

ND 

4.4 

5.8 

.9 

Reuse of Software 

ND 

8.1 

4.3 

5.7 

Rework 

ND 

1.7 

3.5 

.8 


*ND = no data available 

The GOESIM project planned to reuse many of the components 
un-nested by the GOADA developers. However, as apparent by 
the effort needed to rework software, some project-specific 
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dependencies were found within many of these reused compo- 
nents. For example, the Spacecraf t_Ephemeris component from 
the GOADA project logs error data by calling User_ 

Interf ace.Receive_Error . Since telemetry simulators are 
batch programs that typically do not have a user interface, 
all of these calls had to be modified to calls to the Error_ 
Collector . 

3.4 UTILIZATION OF CPU RESOURCES IN DESIGN 

Traditional FORTRAN projects utilize text editors on a com- 
puter system to enter subprogram PDL, COMMON blocks, and 
NAMELISTs before PDR and CDR. The FORTRAN compiler is not 
utilized during design on these projects. Compared to a 
traditional FORTRAN project, central processing unit (CPU) 
resource consumption can be expected to be much higher during 
the design phase of an Ada project that generates a compiled 
design. Two major reasons for this increase are 

• The Ada compiler is being used extensively during 
the design phase. 

• Ada compilers are typically large, complicated pro- 
grams that require substantial CPU resources. 

Figure 3-3 shows the profile of CPU usage over the design 
phases of the GOESIM and UARSTELS projects. The first, 
smaller peak on the UARSTELS project occurred near the PDR. 
The second peak on UARSTELS occurred several weeks before 
the CDR because the project was somewhat ahead of schedule. 
The large peak on GOESIM occurred near the CDR. 
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3.5 SOFTWARE METRICS 


The development of a linkable, compiled system during the 
design phase in Ada is a process similar to implementation 
since a considerable amount of attention must be given to 
details that previously have not been addressed by tradi- 
tional FORTRAN design teams. As a result, it makes sense to 
begin tracking the progress of Ada software projects early 
in the design phase, using software metric tools that tradi- 
tionally have been utilized only during implementation and 
testing . 

One major advantage of developing a compiled design in an Ada 
project is that it represents a clearly defined milestone. 

If a consistent definition of the term is adopted across all 
Ada projects, existing effort data and software metrics .such 
as source lines of code (SLOC), delivered source instructions 
(OSI) or component counts can be used to compute productivity 
during design. These productivity measures can then be used 
to determine, for example, if reported levels of software 
component reuse in design are correlated with actual in- 
creases in productivity during design, if higher productivity 
in design is correlated with a reduction in overall system 
cost, etc. 

The GOADA, GOESIM, and UARSTELS projects, all produced com- 
pilable designs and were compiled to approximately the same 
level of detail. (The GRODY project did not develop a com- 
piled design.) The compiled designs of the production 
simulators are referred to as Build 0. Although the GRODY 
team developed a Build 0 (well after CDR) , major parts of 
the system had not been designed yet, and the system could 
not be linked. 
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Table 3-2. Software Measures for Build 0 



GRODY 

GOADA 1 

GOESIM 

UARSTELS 

SLOC 

19,513 

90,507 

52,831 

49,836 

LOC&C 

ND 

67,684 

39,134 

39,209 

LOC (DSI) 

ND 

36,979 

19,338 

21,350 

Comments 

ND 

30,705 

19,796 

17,859 

Blank lines 

ND 

22,823 

13,697 

10,627 

Statements 

ND 

12,500 

7,212 

8,224 

Declarative 

ND 

7,000 

4,282 

4,636 

Executable 

ND 

5,500 

2,930 

3,588 

Number of com- 

118 

592 

410 

443 


ponents 


1 The data on GOADA was collected about 10 days after the 
CDR; about 2,500 SLOC had already been removed from the 
Build 0 library into the Digital Equipment Corporation (DEC) 
Configuration Management System (CMS) library. These 2,500 
SLOC are not included in the numbers given for GOADA. 


SLOC 

LOC&C 

LOC 

DSI 

comments 
blank lines 


Definiti on of Terms 

Source lines of code => a count of carriage 
returns (<CR>) in the file 

Lines of code plus comments => lines 
containing actual code and comment lines 

Lines of code => lines containing actual code 

Delivered source instructions => same as LOC 

Lines that begin with comment token, " — " 

Lines that contain only a <CR> 


Considerable care must be taken in evaluating lines of code 
as a software productivity measure, particularly for a com- 
piled design. For example, the DSI may not be an appropriate 
measure for the design phase since it excludes all blanks and 
comment lines. Because a large fraction of the PDL for these 
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systems consists of comments, DSI can be expected to somewhat 
underestimate the size of a compiled design. Support for 
this idea can be seen when blanks, comments, and executable 
statements, as a percentage of SLOC for Build 0 of. GOADA and 
GOESIM, are compared with the same percentages for the com- 
pleted GRODY project. 

Table 3-3. Line Count Profiles 


Final Build 

Build 0 at 

CDR 

GRODY 

GOADA GOESIM 

UARSTELS 


Blank lines 
(percent) 

26.0 

25.2 

25.9 

21.3 

Comments 

(percent) 

27.8 

33.9 

37.5 

35.8 

LOC (DSI) 
(percent) 

- 4 . 6^2 . 

40,9 

36,6 

42.9 


100.0 

100.0 ■ 

100.0 

100.0 

LOC&C 

74.0 

74.8 

74.1 

78.7 


(percent) 

Note that the percentage of blank lines is virtually the 
same across GRODY, GOADA, and GOESIM, about 25 to 26 percent. 
However, for the nonblank lines, the ratio of DSI to com- 
ments for the combined GOADA and GOESIM projects at Build 0 
is 1.12, whereas this ratio is 1.66 for the final build of 
GRODY, nearly 50 percent higher. This difference can be ex- 
pected because during implementation, some commented PDL 
statements are modified into executable code, and additional 
executable statements are being added to provide the func- 
tionality summarized in comments written during design. 

Interestingly, approximately 60 to 75 percent of the esti- 
mated final SLOC had been completed by the time of the 
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CDR (Table 3-4). However, as mentioned above, this code 
contains a considerable fraction of commented PDL statements 
whose syntax, semantics, and logic are not subject to the 
rigorous examination of the Ada compiler. Ih other words, 
the effort involved in developing the remaining 25 to 
40 percent of the system during implementation and testing 
can be expected to be greater per line of code than the 
effort involved during design. This hypothesis will be 
examined in the second report in this series. 

Table 3-4. Estimated SLOCs Completed as of CDR 



GQADA 

GOESIM 

UARSTELS 

SLOC at CDR 

90,507 

52,800 

49,836 

Estimated SLOC for final 
system as of October 24, 1988 

145,000 

78,000 

65,000 

Percentage recent estimated 
SLOC completed 

62.4% 

67.7% 

76.7% 


3.6 PRODUCTIVITY 

The total effort for developing Build 0 for the four simula- 
tor projects is shown below: 


Table 3-5. Total Effort for Build 0 


GRODY GQAD A 


GOESIM UARSTELS 


Staff-hours 6,430.0 

Staff-days 1 803.8 


8.144.0 

1.018.0 


4,218.0 

527.3 


3, 008 . 0 

376.0 


^A staff-day is 8 staff-hours. 
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The average productivity measures for each of these projects 
is indicated below. 

Table 3-6. Productivity Measures During Design 



GRODY 

GOADA 

GOESIM 

UARSTELS 

SLOC/staff-day 

24.3 

88.9 

100.1 

132.5 

LOC&C/staf f-day 

ND 

67.8 

74.2 

104.3 

DSI/staf f-day 

ND 

36.3 

36.7 

56.8 

Statements/staf f-day 

ND 

12.3 

13.7 

21.8 

Declarative 

ND 

6.9 

8.1 

12.3 

Executable 

ND 

5.4 

5.6 

9.5 

Component s/s taf f-day 

0.15 

0.58 

0.78 

1.18 


3.7 ADA EXPERIENCE OF DESIGN TEAM 

When the number of years of professional experience in de- 
veloping software in any language are considered for the Ada 
developers, these four simulation projects appear very 
similar, as shown in Table 3-4. Another similarity is that 
the assistant technical representatives (ATRs) and the tech- 
nical managers associated with each project all have had 
experience in developing software in the flight dynamics 
area. On the other hand, for the design phase of these 
projects, the percentage of developers who have had previous 
experience in the application area varies widely, as shown 
in Table 3-4. Similarly, this table also shows a wide vari- 
ation as to the percentage of design personnel who have had 
previous professional Ada software development experience. 
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Table 3-7. Experience of Ada Developers 



GRODY 

GOADA 

GOESIM 

UARSTELS 

Software Development 
Experience (years) 

4.7 

5.9 

5.7 

5.5 

Ratio of Personnel 
Experienced in 
Application 

1/7 

2/7 

1/4 

3/3 

Ratio of Personnel 
Experienced in Ada 

0/7 

3/7 

1/4 

1/3 


As shown in Table 3-8 below, only the GOADA project had a 
technical manager who has had actual Ada software experience. 
Both GOADA and UARSTELS were staffed with a task leader who 
has had previous satellite simulation development experience. 
Only UARSTELS was staffed with a task leader with previous 
Ada experience previous satellite simulation development ex- 
perience, and Ada experience (including satellite simulation 
development experience in Ada) . 


Table 3-8. Ada Experience of Project Management 



GRODY 

GOADA 

GOESIM 

UARSTELS 

Ada Experience of 
Technical Manager 

no 

yes 

no 

no 

Application Area Ex- 
perienced of Task 
Leader 

no 

yes 

no 

yes 

Ada Experience of Task 
Leader 

no 

no 

r 

no 

yes 


5213 


3-14 



This general lack of previous Ada experience during the de- 
sign phase of these projects is due to the relatively recent 
introduction of Ada and the even more recent introduction of 
a production-quality Ada compiler for the VAX. The few de- 
velopers who have had previous Ada experience were drawn 
from the first two GSFC/CSC Ada projects. The three devel- 
opers on GOADA with Ada experience came from FDAS ; the one 
developer on GOESIM with Ada experience came from GRODY; and 
the one developer (also the task leader) on UARSTELS with 
Ada experience worked on both FDAS and GOADA. The technical 
manager of GOADA received his Ada experience from develop- 
ment work on GRODY. 

Since each Ada project gains from both the mistakes and the 
technical advances made by previous Ada projects, it is dif- 
ficult to separate the effect of individual team members' 
application area experience, training, and professional Ada 
development experience from the effect produced by this ac- 
cumulating project legacy. Even so, the one project charac- 
teristic that appears to have a major effect on productivity 
is the presence of a technically strong task leader, with 
professional Ada development experience in the application 
area. 


3.8 TRAINING 

The GRODY team had the widest range of different types and 
forms of training in Ada. Of these, the lectures in PAMELA 
(Cherry, 1985), the classroom lectures on Ada syntax and 
semantics, and the Alsys Ada video training course were rated 
as having only moderate usefulness. In contrast to these, 
the practice project was rated as extremely useful by almost 
everyone on the team, and having actual project experience 
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as a form of training was also highly rated (OJT = on-the- 
job-training) : 

Average rating of the usefulness of each type of train- 
ing provided on GRODY, on a scale of 1 (not useful) to 9 
(extremely useful) : 

PAMELA Lecture Tapes Books OJT Practice -Emiest 
4.4 5.3 5.4 7.0 8.3 8.9 

The GOADA team was provided with classroom lectures on the 
syntax and semantics of Ada, object-oriented design, and the 
use of software development tools. The average rating of 
the training they received was only slightly higher than 
that given by the GRODY team for their lectures: 

Average rating of the usefulness of the training provided 
on GOADA, on a scale of 1 (not useful) to 9 (extremely 
useful) : 

Lecture Books 

6.1 6.1 

One particular criticism of the GOADA training was that the 
timing of the lectures was not well coordinated with the 
project schedule. For example, several developers suggested 
that the lectures on the DEC software development tools 
should have been late in the lecture series rather than 
early. 

Even with the less than enthusiastic rating of classroom 
lectures given by these two teams, most developers across 
all the simulator projects recommended that 40 or more hours 
of classroom lectures should be provided on the Ada language: 

Average number of recommended hours of classroom/lecture 


Ada training 

by project: 



GRODY 

GOADA 

GOESIM 

UARSTELS 

53 

43 

28 

53 
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SECTION 4 - SUMMARY AND RECOMMENDATIONS 


Before these initial Ada projects, almost all software at 
GSFC/CSC has been developed using FORTRAN, a process that is 
well understood in the Flight Dynamics environment. Con- 
versely, the development of software systems in Ada for the 
types of applications found in this environment is a not yet 
as fully an understood process. An understanding of how to 
apply Ada technology more effectively in the Flight Dynamics 
environment can be expected through the accumulated experi- 
ence gained from these projects and from future Ada projects. 

The transition from developing soft ware . sy stems in FQRTRM 
to developing systems in Ada is an evolutionary— P Eflg&aa- 
When the first Ada projects were started, no really well 
defined design methodology existed for use on production- 
level software systems that allowed the design of systems 
that effectively utilized the data abstraction capabilities 
of the Ada language. As a result, an object-oriented design 
methodology and a graphical design notation were developed 
in-house for use on Ada systems; this design technique has 
been incrementally enhanced and refined by subsequent Ada 
projects. The lack of a subsystem concept for the GRODY 
project resulted in the development of a tightly coupled 
system of large compilation units that were not directly 
reusable by follow-on Ada projects. The production simula- 
tor projects all utilized the subsystem concept in their 
designs and extended the GRODY project’s recommendation to 
produce compilable package specifications in developing a 
compiled design. The project UARSTELS greatly increased the 
use of Ada generic packages in design and was the first 
project to emphasize during design the development of soft- 
ware components that could be reused on subsequent projects 
without changes. 
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The design team for an Ada project shoul d have a mixture o ,f 
nprsnnnel with different areas of ex p e rtise end experience . 
These areas include flight dynamics, Ada software system 
development, mathematics, and specific application-area ex- 
perience. In particular, the presence of a technically 
strong task leader with prof e ssional Ada development exper i- 
ence in the application a r ea mav be the Single most importan t 
f actor in producing a well designed system within schedule 
and budget . 

The incremental design a p proach used on the pcoductiQh Ad a 
projects meshes well with the exis ting — RDR/CDR — approach that 
has been utilized on traditional FORTRAN systems. Some con- 
sideration should be given to extending the length of the 
detailed design phase to compensate for the additional effort 
needed to generate the large amount of code associated with 
developing a compiled design. 

All developers expressed a desire for formal training in Ada 
syntax and semantics, Ada software development tools, and 
Ada design methodologies,. Many of these developers suggested 
that this training should be spread out over time, instead of 
a concentrated training presented over a few days. In addi- 
tion, this training should be carefull y c oordinated with the 
project schedule to maximize i ts effectiveness/ particularly 
for training in software development tools. 

Additional thought needs to be give n to how to mo re effe c- 
tively exploit features of Ada i n a manner that will maximize 

the amount of reusability of Ada software design components 

from one simulation project to another. Consideration should 
be given as to how to develop these design entities so that 
they are reusable on larger systems, such as AGSSs, and even 
on very large-scale systems, including the Space Station 
project . 
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GLOSSARY 


AGSS 

ATR 

CDR 

CMS 

CPU 

CSC 

DEC 

DSI 

FDAS 

GOAPA 

GOES- I 

GOESIM 

GRO 

GRODY 

GROSS 

GSFC 

NASA 

PAMELA 

PDL 

PDR 

SLOC 

UARS 

UARSTELS 


Attitude Ground Support System 
assistant technical representative 
critical design review 
Configuration Management System 
central processing unit 
Computer Sciences Corporation 
Digital Equipment Corporation 
delivered source identification 
Flight Dynamics Analysis System 
GOES-I Dynamics Simulator 

Geostationary Operational Environmental 
Satellite-I 

GOES-I Telemetry Simulator 
Gamma Ray Observatory 
GRO Simulator in Ada 
GRO Simulator Systems 
Goddard Space Flight Center 

National Aeronautics and Space Administration 

Process Abstraction Methodology 

program design language 

preliminary design review 

source lines of code 

Upper Atmosphere Research Satellite 

UARS Telemetry Simulator 
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